During elicitation several different methods were used for producing the information required for the documentation.
In this part of the document each method will be discussed and later the results from the different methods will also be subject to discussion.
\\\\
The tracing of elicitation technique of each requirement can be seen at each requirement in the All entities list.

\subsection{Documentation studies}
Our documentation studies were of the product owner's project mission, documentation of products which are to be used by the application, which are the referenced documentation from Google \cite{googlemaps} and Facebook, and the supervisor's supplied documentation, which are the bi-weekly given commentaries of our current requirements and documentation \cite{wnuk}. The documentation studies are accomplished through analysis of the existing documentation that produces a summary of the information which lay within which can be verified and expanded in other elicitation processes.
\\\\
The documentation studies during week two was when the contractors read through the product owner's project mission and elicitated new requirements, areas of interest before the brainstorming and questions for the interview. The documentation studies during week two was done as to prepare the contractors for the interview and brainstorming while also creating a larger understanding of the product owner's wishes for the final product by understanding the present work and present problems. Knowledge such as that the product was to be an application that would be sold to smartphones, the application would show locations near the user on a map, the application would be able to filter the information it show and similar features.
\\\\
The documentation studies of the supervisor's documentation \cite{wnuk} was conducted throughout the project as it was another expanded viewpoint of requirements and completeness, in summary what was important and what the contractors had missed. This generated areas of interest before brainstorming sessions, questions for the interview and new requirements. That further specification had to be done for some of the requirements, a need of more detailed description of how our methods were used, gave the contractors new perspective of stakeholders and similar knowledge.
\\\\
The products that are used by the Get to the point product include but are not limited to Facebook, Android, iPhone, Android market, App Store, Google+ and Google Maps API. Documentation studies were done of those products by reading their EULA, manuals, API and so on. Requirements such as EULA, usage and API were gathered during this elicitation.

\subsection{Stakeholder-Analysis}
By using the known stakeholders and the information the contractors have through other elicitation means a estimation of their goals were made. Through the use of their goals a list of concrete rewards from succeeding in these goals was gathered. With a consideration of risks, costs, future system ideas, commitment and value a list of requirements and information for further elicition studies were made together with a list of possible resources to minimize costs were considered.
\input{stakeholder_analysis.tex}

\subsection{Group Interview}
The group interviews were accomplished through first writing down the questions the contractors had of product, such as present system and goals, and then gathering the groups of interest. The questions are then asked and the answers written down. These interviews were semi structured in the sense that the contractors brought prepared questions but if a answer was hard to understand or unexpected, follow up questions were improvised, that were not written down as there is none such requirement specified anywhere, to get a more thorough picture of the answer. When all questions had been answered they were analyzed by the contractors as to extract requirements and other information from said answers.
\\\\
Only examples of the questions asked are mentioned and as the follow up questions were improvised, as described above, said questions or answers were not written down. Only notes were taken during the interview as to be analyzed afterward.
\\\\
The group interviews were held during week two, three and five. The group interview was held by the contractors and the group owners were the ones that were interviewed.

\newpage
Examples of the questions asked as a list:

\begin{description}
 \item[Week 2 Q1] Which cellphone OS is the product supposed to work with?
 \item[Week 2 Q2] Is the product to be developed to one OS and then converted by a third party to the other?
 \item[Week 2 Q3] Is the product allowed to use the Google Maps API?
 \item[Week 2 follow-up Q4] Which versions of those OS are to be supported?
 \item[Week 3 Q5] Is the application supposed to keep the restaurants in the application now even if the product will focus on specific companies?
 \item[Week 3 Q6] Which filters should still exist on the product after a change of focus?
 \item[Week 3 Q7] Are customers still able to remove pins?
 \item[Week 5 Q8] Should we remove the tutorial?
 \item[Week 5 Q9] Are you sure that the ratings and reviews should exist within an application that is sold to companies? Are you sure companies would like their customers to poorly rate or review them?
 \item[Week 5 Q10] How should the database be handled?
 \item[Week 6 Q11] Här på natten tyckte vi att byta namnet på appen från StoreFinder till Get to the point skulle vara kul, skulle det vara okej för er eller tycker ni att StoreFinder är bättre?
\end{description}
\newpage
The answers to the above questions:

\begin{description}
 \item[Week 2 A1] Android and iOS.
 \item[Week 2 A2] Yes!
 \item[Week 2 A3] Yes!
 \item[Week 2 follow-up A4] All versions that were released before this meeting would be nice.
 \item[Week 3 A5] No, you can remove the restaurants if you so wish.
 \item[Week 3 A6] Favourites, open hours, rating and distance.
 \item[Week 3 A7] No, we would like you to not allow the user to remove pins.
 \item[Week 5 A8] Yes
 \item[Week 5 A9] Right, it probably wouldn't be so popular, especially as only customers whom dislike the application will bother with reviews.
 \item[Week 5 A10] It won't be included in the application as it will be outsourced to a third company.
 \item[Week 6 A11] Get to the Point blir jättebra!
\end{description}

During week two the group interview was done as the contractors had written down the questions ``Which cellphone OS is the product supposed to work with?'', ``Is the product to be developed to one OS and then converted by a third party to the other?'' and ``Is the product allowed to use the Google Maps API?''. The answers were, in order, ``Android and iOS.'', ``Yes!'', ``Yes!''. One of the follow up questions to the OS question was ''Which versions of those OS are to be supported?'' and the answer was ''All versions that were released before this meeting would be nice". For example the goal requirement G3 was elicitated here.
\\\\
During week three the group interview was focused on questions of the possible change of focus of the product. The questions were ``Is the application supposed to keep the restaurants in the application now even if the product will focus on specific companies?'', ``Which filters should still exist on the product after a change of focus?'' and ``Are customers still able to remove pins?''. The answers were, in order, ``No, you can remove the restaurants if you so wish.'', ``Favourites, open hours, rating and distance'' and ``No, we would like you to not allow the user to remove pins.''. The filter requirements were elicitated here, for example the Rating filter (see page \pageref{featureRating}).
\\\\
The week five group interview was a general conclusion of the application requirements. The questions asked was such as ``Should we remove the tutorial?'', ``Are you sure that the ratings and reviews should exist within an application that is sold to companies? Are you sure companies would like their customers to poorly rate or review them?'' and ``How should the database be handled?''. The answers were, in order, ``Yes'', ``Right, it probably wouldn't be so popular, especially as only customers whom dislike the application will bother with reviews.'' and ``It won't be included in the application as it will be outsourced to a third company.''. Database requirements were defined to not be elicitated here and the tutorial requirements were dropped.
\\\\
During a interview week 6 the contractors asked the product owners: ``Här på natten tyckte vi att byta namnet på appen från StoreFinder till Get to the point skulle vara kul, skulle det vara okej för er eller tycker ni att StoreFinder är bättre?'' and the answer was: ``Get to the Point blir jättebra!''. Therefore the contractors considered that the change of the name of FoodFinder to Get to the point was accepted.

%A first group interview with the customer group as a whole regarding the project was also held early on in the project in order to get answers to some of the
%questions about the project mission and to try and limit the scope of the project some.
%It was decided that the application should mainly focus on phones and tablets using iOS or Android OS.
%Further the two groups agreed on that using Google map API was a good idea for implementation later on and this resulted in several requirements, many of these was later removed when the
%project once more changed scope during the study of similar companies. \ref{SimComp}

\subsection{Negotiation} \label{negotiation} \cite{lauren3}
When disagreement rose between groups of interest or conflicts with the business goal a group discussion was held with the product owner where the origin of the conflict was raised. Through negotiations and discussion a solution which was acceptable to the customer was reached by debating different ideas, possibilities, commitment and consequences.
\\\\
Negotiations were held when the contractors elicitated that the product's focus had to change. The product owners considered that the product was to be successful on the market and were unaware of any competition. After the contractors showed the product owners the current competition on their suggested market and what kind of market that the suggested focus would target the product owners agreed with the contractors. The need of a new product name and requirements such as a store focus rather than restaurant focus, for example the requirement that the store cashier should be able to scan the coupon by the QR code, was elicited from this elicitation method.
\\\\
Negotiations were also held during prioritization when there was a large difference between the contractors and the product owners estimations. In case of a negotiation during the prioritization the contractors stated the reasons of their opinions and if the product owners agreed the contractors choice was selected. If the product owners still disagreed their choice was selected.
\\\\
Negotiation was finally held when either the contractors or the product owners changed their minds during validation. For example if the supervisor showed errors of requirements during his validation making the contractors negotiate a different requirement from the product owners. This was used as to change goals which were too vague. When the product owners changed their mind as of validation requirements, for example bookmarks was suggested to be removed, where the contractors informed the product owners that the reason it had been included by the product owners in the first place was as bookmarks are very cheap and is an competitive advantage as the competition lacks bookmarks. After contractor argumentation the product owners changed their mind and accepted inclusion of bookmarks again.

\subsection{Brainstorming}
When the contractors had a lack of information or even questions to ask the contractors tried the brainstorming elicitation technique. The brainstorming was done through two different ways, either with a stakeholder or within the group. The brainstorming with a stakeholder was done by collecting said group to a meeting and letting them say whatever ideas they wished, though focused on the areas of interest by steering the brainstorming and ideas as well as the contractors could.
\\\\
\input{brainstorming_result.tex}
%After the project group had a better understanding of the product from the customer interview a brainstorming session was held within the group.
%Only members were present but a good idea might have been to have someone from the customer group with and discussing requirements on the fly.
%This session resulted in alot of new requirements many later removed in \ref{SimComp}

\subsection{Companies analysis} \label{SimComp}
Applications offering similar services and free-version of competing applications were tested. An analysis of those and the web pages of competing products were done where both business and features were considered. The goal was to get realistic future system ideas and see potential risks.
\\\\
\input{similar}
%At this point a study of similar companies were held and the result came to show that the application that were intended to be developed had no new functionality or selling point compared to other
%existing applications, many of them were also free applications so there was no possibility of competing price wise.
%Thus after a discussion with the customers\ref{focus} the scope of the project was changed to develop an application targeting franchise companies that wants to promote their chain with an application showing stores
%close to the user and having many other features such as coupons and adverticements.

\subsection{Focus group} \label{focus}
The focus group was used to prioritize, validate, verify and create requirements. The reason prioritization and validation occurred was as that there was an attempt to elicitate general areas of interest by letting a focus group discuss matters of prioritization, verification and validation and thereby understanding the features better and therefore the product owners were better at elicitating new requirements. The focus group was done by gathering at least one stakeholder group and then going through general problems and then the solutions of said problems. The goal being to understand the present problems, the future system and having a early understanding of the future system. The priorities were added further as that it's described that focus groups are a great way of prioritisation by Soren Lausen \cite{lauren1}. Then the contractors went through prioritization and validation of the existing requirements and those that came up during the meeting. This step is then reviewed. Everything is led by two moderators. The whole meeting is then analyzed as to understand what has happened and summarizes the outcome.
\\\\
A focus group meeting was held during week three with the product owners and the contractors. Erik Westenius and Oskar Präntare were the moderators at this meeting. The reason of this meeting was to get an early prioritization as to get further knowledge of the requirements that they deemed important. The problem was that there wasn't any understanding of what parts of the application that the product owner desired most vital and therefore the requirements seen in prioritization under Numerical grading were all considered issues at this focus group meeting. So the product owners went through discussing the bad experiences of each of the requirements and discussed the future of those requirements. The product owners then prioritized and validated the requirements that had been created to that point, using the contractors extended knowledge of the product the contractors were able to further discuss individual requirements which had conflicting prioritization between the contractors and the product owners and thereby could formulate new requirements together. Requirements such as that address information of the store should be possible to be viewed that could be decided as the store information features received a high prioritization by the product owners, and thereby awoke a larger discussion of possible interesting store information features.
\\\\
Another focus group meeting was held a few weeks later with the same premises as the last focus group meeting. No requirements were elicitated at this meeting.
%After the study was done a focus group meeting was held were the problem of the compettitors was discussed and a new angle to the project was found.
%During this discussion some new requirements surfaced also some of the requirements from the brainstorming session was also rejected by the customer.
%As mentioned before it might have been more beneficial to have a customer representative present during the brainstorming session.
%All of the resulting requirements from this process can be found in reqT appendix. \ref{KRAVEN} %DENNA REF MÅSTE MED LEDA RÄTT!

\subsection{Task demonstration}
Testers went through the specified task descriptions as to get requirements and find out of the completeness of the requirements. The contractors noticed a need of more requirements to be able to fulfill said task descriptions.
\\\\
The testers went through the task demonstration during week five. The contractors created as of the lack of requirements to fulfill the task descriptions requirements as: ``Use coupon'', ``Hide coupon'' and ``Unhide coupon''.
